Designing a permissions strategy is important when
properly securing database objects. Considering the hierarchy of
securables—a database, a schema, or an object—you have options of
applying permissions by either granting permissions on the database, on
each schema within the database, or on each individual table or view.
The permissions that can be granted and to which securables they can be applied are as follows:
SELECT
Synonyms, Tables and columns, Table-valued functions, Transact-SQL and
common language runtime (CLR), and columns, Views and columns VIEW CHANGE TRACKING Tables and Schemas UPDATE Synonyms, Tables and columns, Views and columns REFERENCES
Scalar and aggregate functions (Transact – SQL and CLR), Service Broker
queues, Tables and columns, Table-valued functions (Transact – SQL and
CLR), and columns, Views and columns INSERT Synonyms, Tables and columns, Views and columns DELETE Synonyms, Tables and columns, Views and columns EXECUTE Procedures (Transact – SQL and CLR), Scalar and aggregate functions (Transact – SQL and CLR), Synonyms RECEIVE Service Broker queues VIEW DEFINITION
Procedures (Transact – SQL and CLR), Service Broker queues, Scalar and
aggregate functions (Transact – SQL and CLR), Synonyms, Tables,
Table-valued functions (Transact – SQL and CLR), Views ALTER
Procedures (Transact – SQL and CLR), Scalar and aggregate functions
(Transact SQL and CLR), Service Broker queues, Tables, Table-valued
functions (Transact – SQL and CLR), Views TAKE OWNERSHIP
Procedures (Transact – SQL and CLR), Scalar and aggregate functions
(Transact – SQL and CLR), Synonyms, Tables, Table-valued functions
(Transact – SQL and CLR), Views CONTROL
Procedures (Transact – SQL and CLR), Scalar and aggregate functions
(Transact – SQL and CLR), Service Broker queues, Synonyms, Tables,
Table-valued functions (Transact – SQL and CLR), Views
Cross-Database Ownership Chaining
Enabled
at the instance level, cross-database ownership enables setting
permissions on one database object such as a view which retrieves data
from two or more tables, or databases in the same instance. This
approach does provide a slight performance increase since permission
checks are skipped on subsequent objects in the chain; taking this
approach has major implications when managing security.
1. Granting Permissions|
You need to add a new login and grant Execute permissions on the AdventureWorks2008 database.
Create a new SQL Server login named Test432 and set the default database to AdventureWorks2008 database. Create
a new database user in the AdventureWorks2008 database, mapping it to
the SQL Server login Test432. Do not give the user any permissions. Execute the following code: GRANT EXECUTE ON DATABASE::AdventureWorks2008 TO Test432 Once
you see, “Command(s) completed successfully”, user Test432 will have to
execute permissions on all the objects in the AdventureWorks2008
database. To test what you’ve done, log in to SQL as Test432 and run the following code: exec dbo.uspGetEmployeeManagers 2
If you do not get an error, your grant worked properly.
|
|
It
can seem like every request brings a new challenge for determining the
best match for permissions when adding a new user to a database. When
business areas consolidate or the responsibilities or business areas
span across multiple business areas such as accounting, where they are
often involved in supporting every other business area in an
organization, it is necessary to construct a list of permissions
requirements before just dropping the user into a role or granting a
permission that looks like it might work.
You
should always be able to justify the choice that you have made. You may
need to explain in significant detail what permissions a user or users
have been granted. Taking the time to gain a thorough understanding of
the SQL Server security hierarchy will greatly help you not only make
the best decisions when designing access, you will have a more secure
instance and be able to speak with confidence when answering questions
in regard to permissions.
|
Object Permissions
Modules
can be marked with an execution context. This enables the code to be
run under a specific security context other than whom or what may be
calling it. As long as the appropriate permissions exist for context in
which the module is run, users only need to be granted permission to
the module. Granting explicit object permissions to the module
reference objects for the module’s users is not necessary.
The following arguments are available when specifying an Execution Context:
CALLER
Statements inside the module are executed in the context of who called
the module. Appropriate permissions must be applied to the module being
called as well as all objects referenced by the module. SELF Equivalent to EXECUTE AS user_name, the specified user is the person creating or altering the module. OWNER The
module is executed in the context of the current module owner or if an
owner is not specified on the module then the owner of the schema of
the module is used. ‘user_name’ The module is executed in the context of the user specified in user_name. ‘login_name’ The module is executed in the context of the SQL Server login specified in login_name.
Log-in Permissions (As Related to Roles)
Logins
can be added to server-level roles which are used to grant server-wide
privileges to a user added to any of the fixed server-level roles. It
is important to remember to make sure that a user is not being granted
more permissions then they need. The server-level roles generally have
the ability to perform tasks beyond the scope of users other than a DBA
or server administrator.
2. Add a SQL Server Login to a Server-Level Role
You will add a SQL Server login to the db_creator server-level role.
Logged
in as sysadmin, Execute the following code (any SQL Server login can be
specified that does not already exist in the db_creator role): exec sp_addsrvrolemember @loginame= 'test432', @rolename = 'dbcreator' Verify that the log-in name you specified is now shown as a member of the db_creator server-level role.
|
